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ABSTRACT 

A  method  is  proposed  for  reasoning 
about  safety  and  liveness  properties  of 
message  passing  networks.  The  method  is 
hierarchical  and  is  based  upon  combining 
the  specifications  of  component  processes 
to  obtain  the  specification  of  a  network. 
The  inference  rules  for  safety  properties 
use  induction  on  the  number  of  messages 
transmitted;  liveness  proofs  use  techniques 
similar  to  termination  proofs  in  sequential 
programs.  We  illustrate  the  method  with 
two  examples;  concatenations  of  buffers  to 
construct  larger  buffers  and  a  special 
case  of  Stenning  protocol  for  message  com¬ 
munication  over  noisy  channels. 

Key  Words  and  Phrases:  communicating 
processes,  mess age- passing  systems,  proofs 
of  process  networks,  safety,  liveness. 

CR-Categories:  C.2.2,  C.2.,4,  D.1.3, 
F.3.1,  F.3.2 

1.  INTRODUCTION 

This  paper  presents  a  method  for  rea¬ 
soning  about  safety  and  liveness  proper¬ 
ties  of  networks  of  processes  in  which 
communication  is  through  messages  only. 

The  k2y  features  of  this  method  ares 

(1)  Modular  Specification:  We  present  a 
scheme  for  specifying  processes  in  a 
modular  fashion.  The  specification 
relies  exclusively  on  a  process's 
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interaction  with  its  environment  and 
is  independent  of  process  implemen¬ 
tation. 

(2)  Hierarchy:  We  present  inference  rules 
by  which  a  specification  for  a  net¬ 
work  is  derived  from  specifications 
of  component  processes.  Thus  the 
proof  of  a  network  is  not  concerned 
with  implementations  of  component 
processes. 

(3)  Compatibility  With  Sequential  Pro¬ 
gramming  Proof  Techniques:  We  have 
extended  well  known  sequential  pro¬ 
gramming  proof  constructs  such  as  pre¬ 
condition,  post- condition  and  the 

Y  ideas  of  termination  proof  to  distri¬ 
buted  systems.  Those  familiar  with 
the  Floyd-Hoare  proof  technique  for 
sequential  programming  should  find 
our  method  to  be  straightforward. 

The  organisation  of  this  paper  is  as 
follows.  We  describe  a  model  of  computa¬ 
tion  in  section  2.  V?e  discuss  the  proof 
technique  in  section  3.  Section  4  con¬ 
tains  the  example  of  concatenations  of 
buffers  to  construct  larger  buffers.  We 
prove  a  special  case  of  the  Stenning  pro¬ 
tocol  for  message  communication  over  noisy 
channels,  in  section  5. 

Apt,  DeRoever,  Francez  11]  and  Levin, 
Gries  [4]  propose  alternate  proof  tech¬ 
niques.  Both  these  works  depend  upon 
analysis  of  code  fragments  of  two  communi¬ 
cating  processes  to  ensure  that  only  de¬ 
sirable  communications  take  place.  Pio¬ 
neering  work  using  temporal  logic  in 
proving  liveness  properties  is  due  to 
Owickl  and  Lamport  [7].  Hailpern  [2]  pro¬ 
poses  proof  techniques  using  temporal  log¬ 
ic  for  general  concurrent  programs  which 
include  both  shared  memory  as  well  as 
message  passing  systems.  A  proof  of  Sten¬ 
ning  protocol  appears  in  Hailpern,  Owicki 

2 .  MODEL  OF  A  NETWORK 

Our  reasoning  technique  is  applicable 
to  a  variety  of  network  models  and  proto¬ 
cols.  However  we  confine  our  discussion 
to  an  extremely  simple  network  model.  In 
this  section  our  goal  is  to  define  a  modal. 
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not  a  programming  language;  hence  syntac¬ 
tic  issues  will  be  treated  informally. 

'A  process  is  cither  a  sequential  pro¬ 
cess  or  a  network  of  processes.  A  sequen¬ 
tial  process  is  a  sequential  program  wi th 
commands  for  message  transmission.  It  may 
have  input  ports  through  which  messages 
are  re ce i vea  and  output  ports  through 
which  messaqes  are  sent.  An  output  port 
of  one  process  may  be  connected  to  the  in¬ 
put  port  of  another  process  by  a  directed 
channel.  A  port  is  connected  to  one  Cha¬ 
nel  and  a  channel  is  always  connected  to 
one  input  port  and  one  output  port.  All 
connections  of  ports  and  channels  are 
static. 

A  sequential  process  h  can  execute  a 
send  command  which  has  the  forms 

send  m  via  p 

where  m  is  a  local  variable  and  p  is  an 
output  port  of  h.  Process  h  continues  exe¬ 
cution  of  its  program  following  execution 
of  the  send  command.  Execution  of  this 
command  results  in  a  message  m  being  sent 
along  the  channel  to  which  output  port  p 
is  connected.  Messages  sent  along  a  chan¬ 
nel  arrive  at  their  destination  in  the 
order  sent  and  after  an  arbitrary  but  fi¬ 
nite  delay. 

A  sequential  process  h  can  execute  a 
receive  command  which  has  the  form: 

receive  m  via  p 

where  m  is  a  local  variable  and  p  an  input 
port  of  h.  Execution  of  this  command  re¬ 
sults  in  the  first  message  (if  any)  which 
has  arrived  at  the  input  pott  p  being  re¬ 
moved  ,  and  its  value  assigned  to  m.  If 
there  is  no  such 'message ,  h  waits  until  a 
message  arrives  at  the  port.  A  process 
can  also  test  whether  there  is  a  message 
at  an  input  port;  for  instance  it  may 
execute  a  statement  of  the  form:  i_f  there 
is  a  message  at  input  port  p  then  si  else 
•2. 

A  network  is  also  a  process  with  input 
and  output  ports.  A  network  consists  of 
one  or  more  component  processes  whose 
ports  are  connected  by  channels.  Any  port 
of  a  component  process,  which  is  not  con¬ 
nected  by  a  channel  to  another  component 
process  port,  is  a  port  of  the  network. 

Example:  A  Sequential  Process:  Merged 

This  process  receives  monotone  increas¬ 
ing  sequences  along  its  two  input  ports 
in(l]  and  in(2)  and  produces  the  merged 
monotone  increasing  output  sequence  along 
its  single  output  port  out.  Its  sequen¬ 
tial  program  is  given  below. 

Process  Merge 2  (input  port  in(l),  inf 2) 9 
output  port  out) 
receive  x^  via  in(l)i 

receive  via  in(2)i 
while  true  do  (loop  forever) 

OT*i  <  *2  Bffl 


begin  nond  x^  via  out; 

receive  x.  via  inf  11 

end 

else  i_f  x2  < 

begin  send  x^  via  out; 

receive  x9  via  in{2J 
end  4 

else  (Xj  =  x2> 

begin  bend  x^  via  out; 

receive  via  1 n ( 1 ) ; 
receive  x_  via  in(2) 

_ j  ^ 


>le:  A  Network:  merge 3 


merge 3  receives  monotone  increasing 
sequences  along  3  input  ports  inflj,  in (21 
and  in(3);  it  outputs  the  monotone  increas¬ 
ing  merged  sequence  along  its  single  out¬ 
put  port  out.  merge 3  can  be  implemented 
as  a  network  of  two  component  merge 2  pro¬ 
cesses. 

3.  PROOFS  OF  PROCESSES 

We  use  some  ideas  from  sequential  pro¬ 
gram  proofs  in  proofs  of  message-passing 
systems.  In  an  annotated  proof  of  a  se¬ 
quential  program,  each  statement  s  has  a 
precondition  pre(s)  and  a  postcondition 
post(s).  The  proof  shows  that  if  asser¬ 
tion  pre(s)  holds  prior  to  execution  of  s, 
post(s)  holds  following  execution  of  s 
assuming  execution  of  s  terminates.  We 
shall  use  the  precondition/postcondition 
concept  for  describing  process  safety  pro¬ 
perties.  Proofs  of  liveness  (or  termina¬ 
tion)  in  sequential  programs  are  based  on 
demonstrating  the  existence  of  a  metric 
such  that  the  execution  of  each  statement 
causes  the  metric  to  decrease  in  value. 

VTe  will  use  a  similar  technique  in  pro¬ 
cess  proofs.  However,  processes  can  wait 
indefinitely  for  messages,  something  that 
conventional  sequential  programs  do  not 
do;  to  handle  this  we  introduce  a  new  con¬ 
cept  called  activity  which  is  the  condi¬ 
tion  under  which  a  process  will  definitely 
send  or  receive  a  message.  Other  liveness 
properties  are  derived  from  the  basic  pro¬ 
perty  of  activity  and  from  safety. 

3.1  Trace 

A  trace  of  a  process  h  is  a  sequence 
of  tuples  <(port|,v.),  (port,, v.) # . • • # 
(portn,vn)>,  where  In  come  computation  the 

ith  message  sent  or  received  by  h  is 
through  port^  and  has  value  v^.  If  port^ 

is  an  output  (input)  port  then  h  sent 
(received)  v^  through  port^.  Thus  the 

trace  is  a  chronological  scqucnco  of  all 
interactions  that  a  process  has  with  its 
environment  in  a  particular  computation. 

An  assertion  r  holds  at  all  points  of 
a  trace  T;  <<portl#v1) , . . . (portn,vft) . . •>, 

if  r  holds  for  all  initial  prefix  traces 


< (portjjVj) . . . (porti,v1) >,  i>0,  of  T.  Note 

that  r  must  then  hold  for  the  null  trace, 
i.e.  the  trace  which  has  no  element.  The 
trace  T*  :  <T;(port,v)>  which  has  T  as 
the  initial  prefix  trace  and  one  more  ele¬ 
ment,  is  called  an  extension  of  T. 

The  sequence  of  messages  transmitted  or 
received  by  a  process  h  via  port,  will  be 
denoted  by  h.port^  (or  port^  whcA  we  are  ^ 

discussing  process  h) .  Let  Z,  Z1  and  Z2 
be  sequences  of  messages.  Then  |z|  is  the 
length  of  Z  and  Z1  a  Z2  denotes  that  21  is 
an  initial  subsequence  of  Z2.  Note  that 
Z  o  Z,  for  all  Z. 

3. 2  Specification  of  a  Process 

We  use  three  propositions  r,  s  and  q  to 
specify  a  process  h,  and  the  specification 

will  be  denoted  by  r- | s  ;  r  is  called  the 

precondition,  s  the  postcondition  and  q 
the  activi ty  condition!  r  and  s  are  asser¬ 
tions  on  traces  of  h  while  q  is  an  asser¬ 
tion  on  the  trace  of  h  and  the  empty/non¬ 
empty  status  of  the  channels  connected  to 
its  ports. 

r|~|s  means  that 
<T 

(1)  s  holds  for  the  null  trace, 

(2)  if  r  holds  at  all  points  of  a  trace 
T  of  h  then  s  holds  at  all  points 
of  any  trace  T*  of  h,  where  T*  is 
an  extension  of  T, 

(3)  if  r  holds  at  all  points  of  a  trace 
^  of  h  and  q  holds  for  T  then  there 
exists  a  trace  T'  of  h  which  is  an 
extension  of  T. 

The  second  condition  does  not  state 
that  the  trace  T  will  be  extended  to  T'j 
it  merely  states  that  if  the  trace  is  ex¬ 
tended  then  s  holds  for  the  extended  trace. 
The  third  condition  is  a  sufficient  condi¬ 
tion  under  which  the  trace  of  h  will  defi¬ 
nitely  be  extended.  Since  all  process 
speeds  are  assumed  to  be  non- zero  and  fi¬ 
nite,  the  phrase  "trace  of  h  definitely 
will  be  extended"  means  that  no  process 
can  have  its  trace  extended  indefinitely 
without  the  trace  of  h  being  extended. 

The  proof  r|^|s  for  a  sequential  pro¬ 
cess,  requires  one  sequential  program 
proof.  A  proof  method  appears  in  |5l, 
when  q  is  absent;  it  has  been  applied  in 
a  number  of  examples  in  (6].  We  have  not 
included  the  proof  method  in  this  paper. 

In  next  section,  we  show  how  the  specifi¬ 
cations  of  a  network  can  be  proven  from 
specifications  of  component  processes. 

3.3  Theorem  of  Hierarchy 

The  theorem  of  hierarchy  gives  the  con- 

ee 

ditions  under  which  we  cat^deduce  ft|g|S, 
for  a  network  H,  given  •  *or  »*1 


processes  h^  in  II.  We  first  present  an 
axiom  -  the  communication  Axiom  <!  -  which 
captures  the  essence  of  the  proposed  com¬ 
munication  protocol.  The  only  assumption 
made  about  the  commun i cm t. i on  protocol  in 
the  theorem  of  hierarchy  is  the  communica¬ 
tion  axiom  C;  therefore  changes  in  the 
protocol  only  affect  C  and  not  the  theorem 
of  hierarchy  directly. 

We  give  C  for  the  model  of  section  2. 

If  there  is  a  channel  linking  the  output 
port  p.  of  process  h^  with  input  port  pj 
of  h2  then  the  sequence  of  messages  re¬ 
ceived  by  h^  through  p.  roust  be  an  initial 
subsequence  of  the  messages  sent  by  h. 
through  p^.  Formally, 

•  P2  ®.  •  P 

Let  the  port  P  of  the  network  H  be  the 
same  as  the  port  p  of  the  component  pro¬ 
cess  h;  then  since  renaming  of  a  port  does 
not  alter  the  message  sequence  through  it, 

H.P  =  h.p 

Combining  these  we  have  the  communication 
axiom, 

C  ::  If  there  is  a  channel  linking 

output  port  of  hj^  with  input 

port  p2  of  h2#  then  h2.p2  «  h^.p^. 

If  port  P  of  H  is  the  same  as 
port  p  of  h,  then  H.P  *  h.p  . 


Given  ri | ^ —  |  ,  for  all  processes 

h . ,  i«l,2,...  in  a  network  H,  we  give  con- 

1  Hi 

ditions  under  which  R|^|S  holds.  Let, 


c  s?a 


V-  r . 


or  _ 
T  qi 


3.3.1  Statement  of  the  Theorem  of  Hierarchy 

h. 


If,  (i)  .1*1, 2,... 


(ii)  s  and  R 


(harmony) 


(iii)  8  ■»>  S,  (abstraction) 

(iv)  s  and  0  •+  <1  (progress) 

<v)  s  and  0  “>  (|  trace  length 
of  h^)  £  P  (trace  length  of  H), 
for  some  function  F  (boundedness) 

then  R|j||S. 

3.3.2  Explanation 

Conditions  (ii)  and  (iii)  deal  with 
safety  and  (iv)  and  (v)  with  liveness. 
Condition  (ii),  called  the  harmony  condi¬ 
tion  says  that  all  preconditions  assumed 
by  the  component  processes  are  implied  by 


the  precondition  of  the  network  II  and  the 
postponditions  of  the  component  processes. 
Condition  (iii),  called  the  abstraction 
condition,  says  that  the  network's  post¬ 
condition  must  be  derivable  from  the  post¬ 
conditions  of  component  processes.  Condi¬ 
tion  (iv) ,  called  the  progress  condition, 
states  that  the  network  can  be  active  only 
if  some  component  process  is  active.  Con¬ 
dition  (v) ,  called  the  boundedness  condi¬ 
tions,  states  that  processes  cannot  send 
or  receive  messages  indefinitely  without 
the  network  communicating  as  well*.  The 
essence  of  the  safety  rules  is:  each  time 
the  trace  of  some  process  h^  is  extended, 

process  h^  guarantees  s^^  (and  hence  s  is 

maintained)  and  harmony  guarantees  r  for 
the  extended  trace. 

4.  AN  EXAMPLE:  CONCATENATION  OF  BOUNDED 
BUFFERS 

4.1  Operational  Description  of  a  Bounded 
Buffer 

A  bounded  buffer  process  of  size  b  is 
shown  schematically  in  Figure  1.  This 
process  can  hold  at  most  b,  b>0,  items  of 
data.  It  is  interposed  between  a  producer 
and  a  consumer.  The  process  sends  requests 
for  data  via  ro  to  the  producer  if  it  has 
room  for  data  (not  all  buffer  spaces  are 
full)  and  if  it  has  no  outstanding  request 
to  the  producer.  It  receives  data  from 
the  producer  through  di.  It  receives  re¬ 
quests  from  the  consumer  for  data  via  ri 
if  it  has  some  data  (the  buffer  spaces  are 
not  all  empty)  and  if  it  has  already  ser¬ 
viced  all  consumer  requests;  it  subse¬ 
quently  sends  data  through  do  in  such  a 
case.  The  goal  of  this  example  Is  to  show 
formally  that  concatenation  of  N# buffers 
of  sizes  b1#b2#...,bN  is  equivalent  to  a 

19 

single  buffer  of  size  £  b. . 

i-1  1 


1 

di 

do 

J 

— > 

— > 

producer 

ro 

^  ri 

Figure  1:  Bounded  buffer  of  size  b. 

4.2  Specification  of  Bounded  Buffer  of 
Size“F - 

The  buffer  process  of  size  b  can  be 
specified  by  the  assertions  r,  s  and  q.  We 
present  each  of  the  assertions  in  a  formal 
notation  and  th?n  explain  in  English*  Xn 
the  following  "a  is  empty,"  where  a  is  a 
port  of  some  process  h,  denotes  that  the 
channel  connected  to  a  is  empty* 

r  tt  true 


4ftoare  terms  this  "absence  of  infinite 
chatter*" 


8  ::  |do|<|rj|  <  | do |  +  1  (si); 

(The  data  to  and  requests  from 
tho  consumer  alternate) 

J  c3_t  |  |  ro  |  |dl|  +  1  (s2); 

(The  requests  to  and  data  from 
the  producer  alternate) 

|ri 1  i  ldi |  (s 3) 

(no  buffer  underflow,  i.e.  no 
request  from  the  consumer  is 
accepted  unless  there  is  data) 

| ro |  £  (do |  +  b  (84) ; 

(no  buffer  overflow) 
do  a  di  (s5); 

{buffer  transmits  the  received 
data  in  sequence) 

q  ::  (|do|  <  |di|  and 

(|do|  <  llil  or  r*  is  not  empty)) 

{buffer  is  not  empty  and  all 
requests  sent  by  the  consumer 
have  not  been  processed;  data 
will  be  sent  to  consumer) 

or  C I  dll  I  <  |do|  +  b  and 

(|ro|  *  |di |  or  di  is  not  empty)) 

(buffer  is  not  full  and  producer 
has  responded  to  all  requests 
for  data;  request  will  be  sent 
to  producer) 

The  problem  is  to  show  that  concatena¬ 
tion  of  any  N  buffers  of  sizes  b1#b2  ... 

bM  has  the  same  specification  as  a  buffer 
N  N 

of  size  E  b. .  We  show  that  the  concate- 
i-1  1 

nation  of  two  buffers  of  sizes  b^b^  has 

the  same  specification  as  a  single  buffer 
of  size.b^  +  bj.  The  proof  follows  for 

N  >  2  in  a  straightforward  manner. 

R 


Figure  2.  Concatenation  of  two 
buffers  of  sizes  b^b^. 

4*3  Proof  of  Bounded  Buffer  Concatenation 
4*3.1  Harmony 

Trivial,  sinco  r  is  true. 


Consumer 


-%  . 


4.3,2  Abstraction 
(Sl)  ,!w|<|ri|<|do|  +  l  ! 
follows  from, 

|h2.do|  <Jh2.ri  | <Jhj.do|  +  1  (s^  for  h2) 

and  the  communication  axiom  C. 

(s2)  Proof  similar  to  (sl) . 

(s3)  |Rl|ilM|s 

|RI |  -  |h2.rl|<|h2.di| (C,  s3  for  h2) 


|h2.di|< |hx.do| 

(C) 

|h^.do  |  <Jh^.di  | 

*  lei 

(sl,s3  for 

,C) 

R0|< |D0|  +  bx  +  b2s 

BO  I  *  |h^.ro|<Jhj.ri| 

♦bl 

(C  and  s4,  sl  for  h^) 

Ih^ril  <.|h2.ro| 

(C) 

(hj.ro l^lhj.do | 

♦  b2 

-I  TO  |  +  b2 
(s4  for  h2#  C) 

(»5)  Similar  to  proof  of  (sl) . 

4.3.3  Progress 

We  will  show  that  If  h^  is  not  active 
(q2  is  false) ,  h2  is  not  active  (q2  is 

false)  and  s  holds  then  H  is  not  active 
(Q  is  false) .  The  negation  of  q^  can  be 

written  as  a  conjunction  of  two  proposi¬ 
tions  ,  (i)  and  (ii) : 

(i)  the  buffer  in  hy  is  empty  (|h^.do|  * 
|h^.dij)  *r  hy  is  waiting  for  requests 
from  its  consumer  h2  ( jh^.do |» |h^. ri | 
and  channel  h^.ri  is  empty),  anJ^ 

(ii)  the  buffer  in  hy  is  full  (|hrdi|  - 
jh^.dol  ♦  b^)  or  hy  is  waiting  tor 
response  from  the  producer  |h2*di|  < 
(^.ro|  and  channel  h^.di  is  empty)  • 

A  similar  set  of  propositions  correspond 
to  *q2  and  -Q* 

Zt  is  straightforward  to  conclude  from 
-q2  and  «q2  that  all  buffers  in  hy  are 

empty  or  all  buffers  in  h2  are  full.  *e 
now  show  that  the  corresponding  conditions 
(i)  and  (ii)  hold  for  n  in  this  case. 
Condition  (i)  for  H  is:  all  buffers  in  » 
are  empty  or  fl  is  waiting  for  requests 
from  the  consumer.  Zf  all  buffers  in  N 
are  not  empty,  then  from  the  observation 


in  the*  first  lino  of  this  paragraph,  all 
buffer;:  in  h2  cannot  be  empty,  and  there¬ 
fore  from  ~q2#  ^2  for  requests 

from  the  consumer.  Condition  (ii)  can  bo 
proven  symmetrically . 

4.3.4  Boundedness 

We  can  show  (cl)  ,  (s2) ,  (s3) ,  (s4) 

for  h^  and  that  the  trace  lengths  of 

hy  and  h2  is  no  more  than  twice  the  trace 
length  of  H. 

5.  STENNING  PROTOCOL  WITH  WINDOW  SIZE  1 

T5T6T - 

Stenning  protocol  can  be  used  to  send 
messages  fro &  a  producer  to  a  consumer 
over  noisy  channels.  Ke  consider  a  spe¬ 
cial  case  of  the  Stenning  protocol  in 
this  paper  -  the  transmitter  sends  a  new 
message  only  after  it  receives  an  ack¬ 
nowledgement  from  the  receiver  for  the 
previous  message;  it  it  receives  no  ack¬ 
nowledgement  within  a  specified  time  • 
period,  it  retransmits  the  message.  The 
full  Stenning  protocol  allows  the  trans¬ 
mitter  to  send  more  than  one  message  with¬ 
out  having  received  acknowledgements. 
Conceptually,  the  proof  of  full  Stenning 
protocol  is  only  slightly  more  difficult 
than  the  one  presented  here;  a  proof  of 
safety  for  the  general  case  using  methods 
of  this  paper  appears  in  (6). 

This  example  illustrates  the  use  of 
the  theorem  of  hierarchy  on  a  problem  in 
which  (1)  the  communication  axiom  C  des¬ 
cribed  earlier  is  no  longer  valid,  since 
a  channel  can  lose,  duplicate  and  permute 
messages  a.^f  (2)  time-out  is  an  essential 
feature  of  the  protocol. 

5. 1  Description  of  Stenning  Protocol 

The  communication  network  is  shown 
within  dotted  lines  in  Figure  3.  For 
simplicity  of  description,  each  channel 
has  a  name  which  is  identical  to  the  port 
names  at  both  ends. 


Figure  X  A  network  to  implement 
Stenning  Protocol. 

The  channels  linking  the  transmitter 
and  receiver  can  lose,  duplicate  or  per¬ 
mute  messages  sent  along  them.  The  trans- 
witter  receives  a  message  from  the  pro¬ 
ducer  and  transmits  it  along  channel  ctr 
after  appending  an  identifying  sequence 
number.  It  continues  to  retransmit  the 
message  after  some  time  unless  it  receives 


/ 


an  acknowledgement  (ack)  for  that  message 
along  crt.  Upon  receiving  an  ack  for  the 
last  message  sent,  transmitter  receives 
the  next  data  item  from  the  producer.  The 
receiver,  upon  receiving  a  data  item  along 
ctr,  checks  to  see  if  it  is  the  last  data 
item  it  has  transmitted  to  the  consumer  - 
in  this  case  it  sends  an  ack  along  crt  - 
or  if  it  is  the  next  item  to  be  trans¬ 
mitted  to  the  consumer  (this  is  deter¬ 
mined  by  the  sequence  number  appended  to 
every  data  item)  -  in  this  case,  it  sends 
the  data  item  to  the  consumer  and  an  ack 
along  crt. 

If  a  channel  loses  all  messages  or 
never  delivers  some  particular  message 
even  if  it  is  transmitted  many  many  times, 
we  cannot  guarantee  eventual  delivery  of  a 
message.  Therefore  we  postulate  the  fol¬ 
lowing  communication  axioms  for  every 
channel  a,  {a. read (v) /a. sent (v)  denotes 
the  number  of  times  message  v  has  been 
received/ sent  along  channel  a), 

(Cl)  a.read(v)  >  0  a.sent(v)  >0, 
for  all  v? 

{every  message  received  must  have 
been  sent} 

(C2)  there  exist  monotone  nondecreasing 
functions  fA#f2  suc** 

f  1  (a. read(v))  <_  a. sent (v) 

f  ^  (a.  read(v) )  for  all  vl 

(every  message  sent  often  enough  will 
be  received  often  enough  and  no 
message  is  duplicated  infinitely 
often.  This  means  ir.  particular 
that  a  sender  process  cannot  be 
infinitely  faster  than  the  receiver 
process ) 

Notation:  To  sinqplify  notation,’ we  assume 
that  every  message  is  a  tuple  consisting 
of  a  sequence  number  (a  positive  integer) 
and  a  data  item.  Thus  the  messages  sent 
by  the  producer  to  the  transmitter,  by 
the  transmitter  to  the  receiver,  by  the 
receiver  to  the  consumer  and  the  acks  sent 
by  the  receiver  to  the  transmitter  are  all 
tuples  of  the  same  form. 

5.2  Specifications  of  Component  Processes 
5.2.1  Specificstlon  of  the  transmitter 
Let  <<c1,v1) . . , (ci,vA) . . . (ch,vJ)>  be 
the  trace. 

r  tt  jth  Item  received  along  port  prod, 
has  sequence  number  j 

•  s«  (1)  ■  prod,  Cj  *  prod,  i  <  j  ~  3k 

i<k< j,  <ck*vk>  -  (crt,vA) 

(A  message  is  received  along  prod 
only  if  ack  to  all  earlier  mes¬ 
sages  have  been  received} 

(2)  cA  -  ctr  -e  3i,  i<J, 


*ci'vi*  ’  (l>rod#v-j)  and  k,  i<k<j( 

<ck,vk>  /  (crt, v^j) 

(A  mcKsace  Is  transmitted  along 
ctr  only  if  it  has  boon  received 
along  prod  and  no  ack  for  it  has 
been  received) 

q  ::  VUcj.Vj)  /  (crt ,prod(N) ) , 

{The  trace  will  definitely  be 
extended  if  an  ack  for  the  N-th 
message  has  not  been  received) 

Note:  It  follows  that  the  last  message 

received  from  the  producer  will  be  retrans¬ 
mitted  indefinitely  often  unless  an  ack 
for  it  is  received.  The  trace  will  be 
extended  as  long  as  ack  for  the  N-th  mes¬ 
sage  has  not  been  received. 

5.2.2  Specification  of  the  receiver 

{<  <cl'vl> ,  •  * '  (ci'vi)  /  •  *  /  (CL/VI#)> 
denotes  the  trace.) 

r  ::  true  {no  assumptions  made  about  the 
input  data) 

s  ::  (1)  Cj  «  cons  ■*  (c^^v^  ^)  «  (ctr,v^) 

{Only  the  last  message  received 
along  ctr  can  be  sent  along  cons) 

(2)  Cj  »  crt  =*  tcj-i  =  cons  Qr 

cj_l  “  ctrl  *nd 
{ v j  a  last (cons) 

=  last (ctr)], 

where  last(Z)  denotes  the  last 
message  sent  or  received  along 
port  Z . 

{An  ack  is  sent  only  if  the 
last (ctr)  and  last (cons)  match. 
Furthermore  at  most  one  ack  is 
sent  after  receiving  a  message.) 

(3)  The  jtn  message  sent  along  cons 
has  sequence  number  j. 

q  ::  c^  *  ctr  and  {v^  *  last (cons)  or 

v^  *  last (cons)  ©  1), 

where  last (cons)  ©  1  denotes  a  mes¬ 
sage  with  sequence  number  1  higher 
than  last (cons). 

(The  receiver  will  extend  its  trace 
if  it  receives  along  ctr,  last(cons) 
or  last (cons)  ©  1;  in  the  former 
case,  it  sends  an  ack  along  crt  and 
in  the  latter  case,  it  also  sends  a 
message  to  the  consumer.) 


5.2.3  Desired  network  proof 

{<1c^, v^) , , (c^« v^) >  is  the  network's 

trace. } 

R  ::  The  jth  message  received  along  prod 
has  sequence  number  j . 

S  ::  ci+1  =  prod  =**  c^  =  cons 

ci+l  =  cons  **  *=  (prod,vi+1) 

{Messages  from  the  producer  and  to 
the  consumer  alternate. } 

Q  : :  1  cons  1  <  H 

{Network's  trace  will  be  extended, 
i.e.  a  message  will  be  received  from 
the  producer  or  sent  to  the  consumer, 
if  all  N  messages  have  not  been  sent 
to  the  consumer. ) 

5. 3  Proof  of  the  Stenning  Communication 
Protocol 


5.3.1  Harmony 

{s  and  R  *•-  r) 
Trivial,  since  R 


transmitter  an<3 


4  receiver  iSS* 

5.3.2  Abstraction 

Lemma  1:  Given  s,  every  message  sent 
along  cons  must  have  been  received  along 
prod. 

Proofs  Every  message  sent  along  cons 
must  have  been  received  by  the  receiver 
along  ctr  (from  sreceiver^*  Every  mes¬ 
sage  received  along  ctr  must  have  been 
sent  along  ctr  {from  channel  axiom  Cl). 
Every  message  s^nt  along  ctr  must  have 
been  received  along  prod  {from 

8 transmitter** 

The  lemma  follows. 

Lemma  2;  Given  s,  the  transmitter 
receives  an  ack  v  only  if  v  has  been 
sent  along  cons. 


Proof:  Follows  from  sM 


and  chan- 


riwi. «  rviiwv  *recei VOT  °ilu 

channel  axiom  cl,  applied  to  channel  crt. 

Proof  of  abstraction  hypothesis:  From 
1mm  1  and  the  fact  that  the  jth  message 
sent  along  cons  has  sequence  number  j*  it 
follows  that  the  sequence  of  messages  sent 
along  cons  is  the  same  as  the  sequence 
received  along  prod.  Therefore  it  remains 
to  show  that  the  network*  operation  alter* 
nates  between  receiving  from  prod  and 
sending  to  cons.  If  *  prod  and  * 

prod,  i  <  J,  in  the  network  trace,  then 
tram  'transmitter'  the  transmitter  »««t 
have  received  v^  along  crt  prior  to  receiv¬ 
ing  Vj  along  prod.  From  lemma  2,  there 


exists  k,  t<k<j  such  that  ® 

(cons,  v^).  It  is  straightforward  to  show 

that  between  every  two  message  sends  along 
cons,  there  must  be  a  message  receipt 
along  prod. 

5.3.3.  Progress 

{s  and  Q  *=*  q) 

Q  says  that  | cons  [  <  N.  From  s,  jth 
data  item  sent  along  cons  has  sequence 
number  j.  Therefore,  no  data  item  with 
sequence  number  N  has  boon  sent  along  cons, 
if  Q  holds.  From  lemma  2,  transmitter 
could  not  have  received  an  ack  for  prod (Nj 
Therefore  qtranslnltter  holds. 

5.3.4  Boundedness 

{s  and  Q  **>  (  l  trace  length  of  h.)  < 
i  1  ~ 

F(trace  length  of  H) , 
for  some  function  F) 

We  show  boundedness  from  s  alone.  We 
will  in  fact  show  a  bound  on  the  number  of 
times  that  any  message  v  is  transmitted 
along  the  channels  crt  and  ctr.  In  any 
computation  of  the  network,  consider  the 
point  at  vrhich  the  transmitter  last  sent 
message  v  along  ctr.  From  stranBmitter, 

transmitter  has  received  0  acks  for  v 
along  crt  at  that  point.  From  channel 
axiom  C2,  receiver  has  sent  no  more  than 
f 2 ( 0 )  acks  for  v.  Since  v  is  the  last 
message  being  sent  by  the  transmitter, 
from  srtCeiver'  the  receiver  sends  an  ack 

every  time  it  receives  v  and  hence  the 
receiver  could  not  have  received  v  more 
than  f2(0)  times.  Therefore  from  C2 

transmitter  could  have  sent  v  at  most 
f 2 (f 2  (0) )  times.  A  message  is  received 

a  bounded  number  of  times  if  it  is  sent 
a  bounded  number  of  times  (from  C2) .  The 
result  follows. 

6.  CONCLUSION 

The  goal  of  this  paper  has  been  to  ex¬ 
tend  the  ideas  of  sequential  program  prov¬ 
ing  to  proofs  of  message  communicating 
systems.  Ideas  of  pre-  and  post  condi¬ 
tions  and  boundedness  seem  to  have  natural 
analogs  in  message  passing  systems.  It  is 
hoped  that  the  full  power  of  sequential 
program  proving  methods  can  be  applied  to 
these  systems;  to  do  so  vc  need  to  develop 
a  convenient  notation  for  descriptions  of 
traces  and  operations  on  them. 
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